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MANAGEMENT SYSTEM FOR REMOTELY MANAGING A DATA 
PROCESSING SYSTEM VIA A COMMUNICATIONS NETWORK 



FIELD OF THE INVENTION 

This invention relates to a management system for remotely managing a data 
processing system via a communications network, such as the Internet. 

BACKGROUND 

Business entities may exchange information over a communications network such as 
the Internet. For example, one business entity may engage in transactions with a group of 
trading partners. The business entities may exchange information about transactions in 
goods, transactions involving a service, financial transactions or other information to 
enhance business operations. Electronic communications may promote transactional 
efficiency, such as reduction of clerical errors from reduced human intervention or increasing 
the speed of executing transactions. 

In the context of a business-to-business communications environment, each trading 
partner that is a participant in the transaction or communication may maintain a data 
processing system (e.g., a server) to support the communication. However, the trading 
partners may make conflicting technical decisions on the maintenance of hardware and 
software for various data processing systems involved in the business-to-business 
communications environment. Trading partners may not share adequate technical 
information with each other or may simply fail to coordinate the installation of software 
upgrades, even where adequate technical information about other trading partners is 
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available. For example, different trading partners may decide to upgrade their hardware or 
software platforms at different times which may result in the incompatibility of one or more 
software features or the inability to conduct a transaction. To avoid disruption of 
transactions or problems in the interoperability of technology and software functionality, the 
trading participants may agree to have upgrades and revisions handled by a single provider. 
Thus, a need exists for facilitating the single provider's management of the technical 
parameters of data processing systems of trading participants that may interact. Further, the 
need exists for efficiently providing software features and software upgrades for the trading 
participants in a business-to-business environment. 

SUMMARY 

In accordance with the invention, a management system communicates with at least 
one remote data processing system, associated with a trading participant, on a technical 
parameter of at least one remote data processing system. A technical parameter may refer to 
software specifications, hardware specifications, operational status of a data processing 
system, operational status of a software component of the data processing system, 
operational status of a hardware component of the data processing system, or any 
combination of the foregoing items. The management system receives a report message on 
the technical parameter via a communications network. The management system interprets 
or processes the report message for a presentation on a user interface of the management 
system. The management system presents the report message or another presentation on the 
user interface for review by a user. 
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In accordance with another aspect of the invention, the management system supports 
the upgrading of a software module resident in one or more remote data processing systems. 
In accordance with another aspect of the invention, the management system facilitates the 
upgrade of a software version of at least one software module at a remote data processing 
system to provide consistent technical interoperability between a base data processing system 
and one or more remote data processing systems. Accordingly, the management system is 
well suited for maintaining reliable communications and facilitating efficient transactions 
among the trading partners in a business-to-business, electronic commerce environment. Via 
the management system, a single service provider is able to upgrade the technical parameters 
of the business-to-business system in a uniform way that keeps the functionality of the 
remote data processing systems up-to-date without causing disruptions in communications 
from platform conflicts or other communication problems. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a business-to-business system including a management 
system in accordance with the invention. 

FIG. 2 is a block diagram of the business-to-business communications system in 
greater detail than FIG. 1 . 

FIG. 3 is a flow chart of a method for monitoring a remote data processing system or 
systems from a management system in accordance with the invention. 
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FIG. 4 is a block diagram of a business- to-business system that supports monitoring 
of transactional data and confirmation data from a user interface in accordance with the 
invention. 

FIG. 5 is a chart of transactional data and associated performance data that may be 
accessible via a management system of the invention. 

FIG. 6 is a block diagram that illustrates an alternate embodiment of a remote data 
processing system in accordance with the invention. 

FIG. 7 is a block diagram that illustrates an alternate embodiment of a business-to- 
business system with multiple remote management systems at different sites in accordance 
with the invention. 

FIG. 8 A and FIG. 8B are a flow chart of a method for updating a software module in 
accordance with the invention. 

FIG. 9A and FIG. 9B are a flow chart of a method for adding a new feature to a 
remote data processing system via the management system in accordance with the invention. 

FIG. 10 is a block diagram of an alternate embodiment of a business-to-business 
system in accordance with the invention. 

DETAILED DESCRIPTION 

In accordance with the invention, a business-to-business system 10 of FIG. 1 includes 
a primary business system 70 coupled to a base data processing system 12. The base data 
processing system 12 communicates with one or more remote data processing systems 18 via 
a communications network 16 (e.g., a virtual private network on the Internet). Each remote 
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data processing system 18 is coupled to a corresponding secondary business system 72. A 
management system 14 is coupled to the communications network 16, the base data 
processing system 12, or both. The management system 14 facilitates remotely monitoring 
technical parameters and remotely altering technical parameters of one or more remote data 
processing systems 18. A technical parameter generally refers to a software specification or 
characteristic of a data processing system, a hardware specification or characteristic of a data 
processing system, operational status data on a data processing system, operational status 
data on a software component of the data processing system, operational status data on a 
hardware component of the data processing system, or any combination of the foregoing 
items. The data processing system generically refers to the base data processing system 12, 
the remote data processing system 18, or both. 

The primary business system 70 may exchange transactional data with one or more 
secondary business systems 72 via the communications network 16 to conduct a business-to- 
business transaction. To this end, the base data processing system 12 and at least one remote 
data processing system 18 act as intermediaries to facilitate communications via the 
communications network 16. For example, the base data processing system 12 may convert 
transactional data from the primary data processing system into an extensible mark-up 
language document (XML), a hyper-text mark-up language (HTML) document, or any other 
suitable data structure for transmission of transactional data over the communications 
network 16. Similarly, the remote data processing system 18 may convert the received 
transactional data from the base data processing system 12 from an XML document, an 
HMTL document, or another suitable data structure into a data protocol or format compatible 
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with the secondary data processing system 72. The transactional data (e.g., XML document) 
may be transmitted as one or more data packets over the communications network 16, 
consistent with the hypertext transfer protocol (HTTP), hypertext transfer protocol, secure 
(HTTPS), or any other suitable data protocol. HTTP and HTTPS define how data messages 
are formatted and transmitted, for example. 

The primary business system 70 may manage transactional data or other data relevant 
to the business operations of a primary business entity. For example, the primary business 
system 70 may represent an enterprise resource planning system. An enterprise resource 
planning system refers to a computer system that may integrate one or more of the following 
business functions of an entity: manufacturing, accounting, management, purchasing, 
inventory control, and engineering. The base data processing system 12 may represent the 
business-to-business server of a primary business entity. 

The secondary business system 72 may manage transactional data or other data 
relevant to the business operations of a secondary business entity. The secondary business 
system 72 may represent an enterprise resource planning system or another computer-related 
tool for managing a business entity. The primary business entity or an affiliate may be 
allocated the responsibility of maintaining and upgrading the software of the remote data 
processing systems 18. The remote data processing systems 18 may be controlled by a 
secondary business entity or a number of different secondary business entities, distinct from 
the primary business entity. 

The base data processing system 12 may engage in a transaction with one or more 
remote data processing systems 18 over the communications network 16. Although any 
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number of remote data processing systems 18 may be used to practice the invention, in FIG. 
1 the remote data processing system 18 may be designated a first remote data processing 
system 74, a second remote data processing system 76, and a third remote data processing 
system 78. Further, the first, second and third remote data processing systems (74, 76, and 

i 78) may be affiliated with a first business entity, a second business entity, and a third 

business entity, respectively. The first business entity, the second business entity, and the 
third business entity represent secondary business entities, whereas a business entity of the 
base data processing system 12 represents the primary business entity. 

The management system 14 may monitor a transaction or communication between the 

) base data processing system 12 and any remote data processing system 1 8; particularly with 

respect to the functionality of application software of a base data processing system 12 and 
the remote data processing systems 18. Further, the management system 14 may monitor 
system level or network level communications between the base data processing system 12 
and one or, more remote data processing systems 18 to ensure reliable communications and a 

5 fault-tolerant environment. 

The monitor 36 supports remote monitoring of the following attributes of remote data 
processing systems 18: (1) system monitoring of one or more interactions between the base 
data processing system 12 and the remote data processing system 18 via the communications 
network 16; (2) application monitoring of application software of the base data processing 

) system 12, the remote data processing system 18, or both. System monitoring refers to 

monitoring of one or more system components that support application software (e.g., 
business-to-business application software). A system component refers to any software or 
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hardware that supports application software. A hardware component may include electrical 
connections between hardware components, a hard drive of a server, a server, a database 
manager 44, a database, and brokering architecture, among other items. A base data 
processing system 12 or a remote data processing system 18 may comprise a server (e.g., a 
business-to-business server). Brokering architecture may refer to any intermediate data 
processing system that interfaces one business system (e.g., primary business system 70) to a 
communications network 16 to support communications of data messages to another 
business system (e.g., a secondary business system 72) of a trading partner. The remote data 
processing system 18 or the base data processing system 12 represents an intermediate data 
processing system. 

Applications monitoring refers to the monitoring of a software application (e.g., a 
software module), and may extend to the transactions that the software application supports. 
An active remote software module 60 (FIG. 2) or an active base software module 22 (FIG. 2) 
may represent applications software or a business-to-business software application. 

The management system 14 supports remote monitoring, remote configuration, or 
both of software components of the remote data processing system 18. In one embodiment, 
the management system 14 allows a user or service provider to add, delete, or modify the 
software features of each remote data processing system 1 8 without requiring a person or 
technician to be at the location of the remote data processing system 18 where the software 
changes are proposed or being made. The management system 14 is particularly well suited 
for configuring a group of remote data processing systems 18 to promote technical 
compatibility. For example, the management system 14 may reduce travel expenses that 
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might otherwise be necessary to upgrade remote data processing systems 18 of different 
trading partners, which may be widely geographically dispersed. A trading group refers to a 
set of trading partners (i.e., business entities) that exchange information with each other via a 
communications network to conduct a transaction or otherwise support business-to-business 
commerce. 

FIG. 2 shows an illustrative example of components that may be used to practice the 
configuration of FIG. I. Like reference numbers in FIG. 1 and FIG. 2 indicate like elements. 

The base data processing system 12 may refer to a business- to-business server or 
another computer intermediary that provides a communications interface between a primary 
business system 70 and a communications network 16. The base data processing system 12 
may include a processor 20 in communication with a base status reporter 24 and a base 
communications interface 26. The processor 20 may execute an active base software module 
22, which may be stored in a storage device (e.g., memory). For example, the active base 
software module 22 may support an electronic transaction with a trading partner with a 
complementary active remote software module 60 via a communications network 16. The 
base status reporter 24 may provide a local report message on technical parameters, 
operational status, or both pertaining to the base data processing system 12 or any of its 
constituent components. The base communications interface 26 supports communications 
between one or more of the following: the management system 14 and the remote data 
processing system 18. The lines interconnecting the components of the base data processing 
system 12 may represent logical data paths, physical data paths, or both. 
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The management system 14 includes a managing communications interface 28 that is 
a coupled to a data processor 30. In turn, the data processor 30 is coupled to a user interface 
34 and a storage device 32. The lines interconnecting the components of the management 
system 14 may indicate logical data paths between the components, physical data paths 
between the components, or both. 

The managing communications interface 28 may include a first port 81 for monitoring 
a base data processing system 12 and a second port 83 for monitoring the communications 
network 16. The traffic at the second port 83 may not be filtered by any firewall associated 
with the base data processing system 12 to allow greater flexibility in surveillance of the 
traffic on the communications network 16. 

The data processor 30 includes a monitor 36, an interpreter 38, a controller 40, a 
database manager 44, and a presentation module 42. The monitor 36 may receive data from 
the managing communications interface 28. The received data may originate from the base 
data processing system 12 or one or more remote data processing systems 18 via the 
communications network 16. 

The interpreter 38 extracts or accepts technical parameter data or processed technical 
parameter data from the monitor 36. The interpreter 38 refers to an evaluator that interprets 
or evaluates the monitored technical parameter data to determine whether and how the 
monitored technical parameter data is relevant to operational status, maintenance or 
upgrading. The interpreter 30 may establish alarm criteria that represents the need for 
undergoing an update procedure or a new feature upgrade of the remote software module 60, 
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for example. The interpreter 38 may forward interpreted information to the presentation 
module 42. 

The presentation module 42 prepares information for presentation by a user interface 
34, such as a graphical user interface 34. For example the presentation module 42 may 
arrange the information by identity of different trading partners or different transactions. 

The database manager 44 may communicate with the interpreter 38, the managing 
communications interface 28, a storage device 32, and other components of the data 
processor 30, where necessary or appropriate. The storage device 32 stores one or more of 
the following databases: a reference parameters database 46, a received parameters database 
48, and an upgrade module database 50. The database manager 44 manages query, storage 
and retrieval operations from one or more data bases stored within the storage device 32. 

The reference parameters database 46 stores the reference technical parameters on the 
remote data processing systems 18. For example, the reference technical parameters may 
include the following information on each remote data processing system 18: a remote 
identifier (e.g., server identifier), hardware specifications, software specifications, a software 
module identifier, a software version identifier of each software module, operational status 
data (e.g., acceptable ranges of performance metrics), and any other data relevant to the 
proper technical operation of the remote data processing system 18 for communications and 
conducting transactions over the communications network 16. Each remote data processing 
system 18 may be identified by a remote identifier to support different configurations at the 
different remote data processing systems of a trading group or multiple trading groups. The 
remote data processing system of the same trading group may be assigned a group identifier. 
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The received technical parameter database contains received technical parameters on 
the actual technical parameters (e.g., specifications or actual operational parameters) of the 
remote data processing system 18. The reference technical parameters may define a 
reference or desired configuration of a corresponding remote identifier or trading group 
identifier. In contrast, the reference parameters contain reference data on the remote data 
processing system 18. 

In an alternative embodiment the received technical parameter database may be 
omitted from the storage device 32. 

The storage device 32 preferably includes an upgrade module database 50 for storing 
software modules for new features, revisions or updates of the remote data processing 
systems 18. For example, the upgrade module database 50 may include an upgrade remote 
software module, a desired version (e.g., latest version) of an upgrade remote module, an 
upgrade base software module, a new version of an upgrade base software module, or any 
combination of the foregoing items. The data processor 30 may select and extract a requisite 
or desired upgrade module from the upgrade module database 50 based on a comparison of 
the received technical parameters to reference technical parameters in the reference 
parameters database 46. The database manager 44 forwards the requisite upgrade software 
module or desired version (e.g., new version) of the software module to the managing 
communications interface 28. In turn, the managing communications interface 28 sends the 
upgrade software module to one or more remote data processing systems 1 8 that require an 
upgrade or desired version via the communications network 16. The communications 
network 16 may refer to the Internet, an intranet, a virtual private network, a dedicated 
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communications line, a public switched telephone network (PSTN), a data packet network, a 
virtual communications path, a physical communications path, or another 
telecommunications link. 

Each remote data processing system 18 may include a remote communications 
interface 52 that supports communications with the managing communications interface 28 
via the communications network 16. Each remote communications interface 52 may 
maintain a remote identifier (e.g., a remote station identifier) for facilitating selective 
communications over the communications network 16 between one or more of the following 
network elements: (1) the base data processing system 12 and a corresponding remote 
processing system and (2) a management system 14 and a corresponding remote data 
processing system 12 (e.g., first remote data processing system 74) 

The remote communications interface 52 of the remote data processing system 18 
may communicate with a remote control module 54. The remote control module 54 may 
contain a revision module and an interface for communicating to a storage device 62. The 
remote control module 54 may supervise the holding of an upgrade module or desired (e.g., 
new) version of a software module sent from the management system 14 to the remote data 
processing system 1 8, until the upgrade can be made at a suitable time. The suitable time 
may be established by coordinating the upgrade with ongoing transactions such that a 
ongoing transaction between the remote data processing system 18 and the base data 
processing system 12 is not interrupted by the upgrade of the software module. Further, the 
suitable time may require the remote control module 54 to wait to upgrade a software module 
in the remote data processing system 1 8 until confirmation or verification is received that the 
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remote data processing system 18 has adequate hardware to support the upgrade software 
module. If the hardware of a particular one of the remote data processing systems 18 is 
inadequate to support the upgrade, the remote status reporter 56 may send a data message to 
the management system 14 indicating that a hardware upgrade is necessary. The hardware 
upgrade may require the dispatch of a technician to the remote site where the particular one 
of the remote data processing systems 18 resides. 

The remote status reporter 56 may provide general status information on the technical 
parameters of the remote data processing system 18. The technical parameters may include 
the technical specifications, operational status, or both of the remote data processing system 
18. Operational parameters include transactional data and application functionality of the 
remote data processing system 1 8. The remote status reporter 56 may monitor the hardware 
operations, software operations or both of the remote data processing system 18 to provide 
the management system 14 with technical parameter data for archiving in a remote 
performance database 64 or transmission to the management system 14. The remote 
performance database 64 may be stored in the storage device 62 for subsequent transmission 
to the management system 14 for display via the user interface 34 or archiving the received 
parameters database 48. 

The remote data processing system 18 includes one or more active or installed remote 
software modules 60. The remote status reporter 56 can provide an inventory of the active or 
installed remote software modules 60 as received technical parameter data to determine 
whether an upgrade revision or new version of the remote software module 60 is required in 
the form of an upgrade module or a new version of a remote software module 60. An 
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inventory may refer to a list of installed remote software modules 60 by module identifier, 
for example. 

The user interface 34 may be used to display the status report that the remote status 
reporter 56 transmits. The presentation module 42 may format the received status report to 
inform a user of functional problems or operational problems in the remote data processing 
system 18 that may require attention. The status report may include a remote identifier to 
identify the particular problematic remote data processing system . Accordingly, if the 
management system 14 is monitored by a human or live operator, the operator may well 
represent a single point of network service and operations management for all of the trading 
partners of the business-to-business environment. 

The foregoing upgrade functionality of the base data processing system 12 and the 
management system 14 supports efficient software upgrades and troubleshooting of remote 
data processing systems 18 without the need to dispatch a technician to various geographic 
locations (e.g., sundry cites) of different trading partners. Thus, the configuration is well 
suited for trading partners that are widely geographically dispersed such that traveling 
expenses of technicians and time involved in the upgrade may be greatly reduced over 
manual upgrades that would otherwise involve a technician loading software into one or 
more remote data processing systems 18 via an optical media such as a compact-disk, read- 
only-memory (CD ROM disk), a magnetic tape, a floppy disk or a removable disk drive. 

FIG. 3 is a block diagram of a method for monitoring the operation of one or more 
remote data processing systems 18 via a communications network 16. The management 
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system 14 may support the monitoring operation of FIG. 3. The method of FIG. 3 starts in 
stepS 10. 

In step S10, the management system 14 or the base data processing system 12 polls or 
communicates with one or more remote data processing systems 18 via the communications 
network 16. For example, the management system 14 may transmit a data message query to 
remote business-to-business servers as the remote data processing systems 18. Each remote 
data processing system 1 8 may be associated with a different trading partner. The polling 
may seek information on at least one technical parameter of software, hardware or both of 
each respective remote data processing system 18. The technical parameter may comprise a 
technical specification or characteristic of a particular remote data processing system 18 or 
an operational status of a particular remote processing data system 18. For example, the 
operational status may represent transactional data that is provided by a secondary business 
system 72. 

In step SI 2, the management system 14 or the managing communications interface 28 
receives a report message on the at least one technical parameter via a communications 
network 16. For example the remote status reporter 56 may obtain technical parameters 
(e.g., operational status data) of the remote software module 60 of the remote data processing 
system 18. After gathering the technical parameter data the remote status reporter 56 may 
forward the technical parameter data to the remote communications interface 52 where the 
remote communications interface 52 conveys the technical parameter data to the managing 
communications interface 28 via the communications network 16. 
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At the management system 14 in step S 14, the data processor 30 or the interpreter 38 
interprets the report message or the underlying technical parameter data for a presentation on 
a user interface 34. For example, the interpreter 38 may organize or filter the received report 
messages from different remote data processing systems 18. The information may be 
displayed at the user interface 34 (e.g., graphical user interface 34) by the identity of 
different trading partners having associated corresponding remote data processing systems 
18. 

In one confirmation, the interpreter 38 may organize a filter for display based upon a 
defined alarm or the occurrence of a triggering event. The defined alarm may be established 
where a pre-designated condition is established as a trigger for displaying the alarm or 
alerting a user at the user interface 34. For example, a pre-designated condition may include 
the occurrence of a particular transaction with certain characteristics or a operational status 
of hardware, a software module, or both. 

In step SI 6, the report message is presented on a user interface 34 for review. The 
information or report message presented to the user may afford the user the opportunity to 
authorize a manual upgrade or revision of software (e.g., a remote software module 60) in a 
remote data processing system 18, the base data processing system, 12, or both. The user 
may resolve a compatibility problem or engage in other troubleshooting action to enhance 
reliability in the communications network 16 based on an interpretation of the report 
message or other monitored information provided by the remote status reporter 56. 
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FIG. 4 shows an illustrative exchange of data in a business-to-business system in 
accordance with the invention. Like reference numbers in FIG. 4 and FIG. 1 indicate like 
elements. 

S 

A user interface 102 is coupled to the primary business system 70. In turn, the 
primary business system 70 is coupled to a base data processing system 12. The base data 
processing system 12 communicates with a remote data processing system 18 via a 
communications network 16. The remote data processing system 18 is coupled to a 
secondary business system 72. The management system 14 (e.g., a monitoring system) is 
coupled to the base data processing system 12 for monitoring the status of one or more of the 
following: confirmation data 103, transactional data 101, a software module, and a 
component of the remote data processing system 18. The management system 14 can 
monitor and configure the remote data processing system 18. However, the management 
system 14 is not necessarily configured to monitor or configure the secondary business 
system 72 because of security measures (e.g., a firewall) and other technical considerations. 

The user interface 102 supports monitoring of the system on a transactional or 
business level. For example, the user interface 102 may allow a user to enter or approve 
transactional data 101 associated with the primary business system 70. The primary business 
system 70 interacts with the secondary business system 72 to convey or exchange the 
transactional data 101 over the communications network 16. For example, the primary 
business system 70 may send transactional data 101 to the secondary business system 72 via 
the communications network 16. The secondary business system 72 may generate 
confirmation data 1 03 or an acknowledgement upon receipt of the transactional data 101, 
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successful execution of the transactional data 101, or both. If a communications fault or 
another problem is present in the business-to-business system of FIG. 4, the primary business 
system 70 may not receive the confirmation data 1 03. 

A user may monitor and review transactional data 101 and associated confirmation 
data 103 on the user interface 102 to detect problems at a business level or transactional 
level. In general, only the party entering transactional data 101 can change the transactional 
data 101 to resolve a transactional problem so as to avoid deletion, corruption, or unwanted 
changes to the transaction underlying the transaction data. If a problem is identified, a 
management system 14 may provide a technical analysis of the problem in greater detail than 
that available to the user interface 1 02. 

FIG. 5 provides a chart of a representation that a management system 14 may provide 
for reviewing the transactions of a group of trading partners in a trading group. The first 
column represents trading partner identifiers 104. In the example shown, the trading partner 
identifiers 104 refer to a first trading partner 109, a second trading partner 1 10, and a third 
trading partner 1 1 1 through an Nth trading partner 112. 

The second column refers to transaction identifiers 105. Each transaction identifier 
105 refers to a symbol, a code, or a number that represents a unique identifier to distinguish 
one transaction from another. The transaction identifiers 105 may include revision codes, if 
the same transaction is attempted multiple times. 

The third column contains transmittal times 106. The transmittal time 106 refers to a 
time and date in which transactional data 101 was transmitted from the base data processing 
system 12 to the remote data processing system 18 over the communications network 16. 
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Altematively, the transmittal time 106 refers to the time and date in which the primary 
business system 70 sends the transactional data 101 to the base data processing system 12 for 
transmission to the remote data processing system 18 via the communications network 16. 

The fourth column represents acknowledgement receipt time 107. The 
acknowledgement receipt time 107 refers the time when the base data processing system 12 
or the primary business system 70 receives acknowledgement data transmitted by the 
secondary business system 72, the remote data processing system 18, or both. In one 
embodiment, the secondary business system 72 generates and sends acknowledgement data 
in response to the successful receipt (e.g., received and detectable without a significant error 
rate that detracts from data reliability) of transactional data 101. The acknowledgement data 
is sent to a business entity identifier that is associated with the transactional data 101. In 
another embodiment, the remote data processing system 18 generates acknowledgement data 
or sends feedback data to the base processing system 12. The management system 14 may 
review the acknowledgement data or the feedback data to provide a fault analysis, a 
troubleshooting analysis, or the like. 

The last column of FIG. Srepresents status data 108. The status data 108 may be 
derived from or expressed as the feedback data, the acknowledgement data, or both. 
Although a myriad of possible status representations exists, as shown in FIG. 5 the status 
data 108 includes one or more of the following states: transaction complete, transactional 
data 101 not received, transactional data 101 corrupt, remote data processing system 18 is 
down, communications network 16 is down, and secondary data processing system is down, 
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an installed remote software module 160 or a component of the remote data processing 
system 18 is not operational. 

FIG. 6 is a block diagram of an alternate embodiment of a remote data processing 
system 118 that supports various fault analysis procedures in accordance with the invention. 
The remote data processing system 118 may convey the fault analysis data (e.g., trouble- 
shooting report) to or otherwise make the fault analysis available for review by the remote 
management system 14. Like reference numbers in FIG. 1 and FIG. 6 indicate like elements. 

In FIG. 6, the primary business system 70 is coupled to base data processing system 
12. The base data processing system 12 communicates with a remote data processing system 
1 18 via the communications network 16. In turn, the remote data processing system 18 is 
coupled to the secondary business system 72. The primary business system 70 and the 
secondary business system 72 may interact by using the base data processing system 12 and 
the remote data processing system 1 18 as intermediaries. The remote management system 14 
monitors the base data processing system 12, the remote data processing system 1 18, or both. 

The remote data processing system 118 of FIG. 6 differs from the remote data 
processing system 18 of FIG. 1 in the following respects. First, the remote data processing 
system 118 of FIG. 6 includes a multi-stage, remote software module 160. Second, the 
remote status reporter 156 includes a fault detector 165 and a feedback generator 164. 

Although the multi-stage, remote software module 160 may include any number of 
stages, in FIG. 6, three stages (161, 162, 163) are shown. The stages (161, 162, 163) are 
designated as a first stage software component 161, a second stage software component 162, 
and a third stage software component 163. The lines interconnecting the stages (161, 162, 
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163) indicate logical data paths, physical data paths, or both. The stages (161 , 162, 163) are 
arranged in tandem or series such that transactional data 101 or another data message 
received from the base data processing system 12 via the communications network 16 is 
processed successively by each of the stages (161, 162, 163) or in some other defined order. 
Once one stage has initiated or completed processing the data message (e.g., transactional 
data) or a derivative thereof, the data message or its derivative is typically passed on or 
handed of to the next stage, unless the remote multi-stage software module 160 is not 
functioning appropriately or unless the processing of the next stage is not required. 

The fault detector 165 detects whether the software module 160 is functioning 
appropriately by tapping into the logical data paths or physical data paths between the stages 
(161, 162, 163). If the data message (e.g., transactional data 101), its derivative, or its 
precursor is present at an earlier stage and absent at a later stage after the earlier stage has 
initiated or completed its processing, the fault detector 165 may determine that the stage 
immediately following the last detected data message is at fault. The fault detector 165 may 
assign a stage identifier to distinguish one stage from another and to identify a faulty stage. 
Further, the fault detector 165 may associate a fault description (e.g., a fault code) with the 
stage identifier for transmission to the remote management system 14 or the base data 
processing system 12 via the communications network 16. 

The fault detector 165 may archive its analysis or detected faults, stage identifiers, 
and fault descriptions in a database 200 associated with the remote data processing system 
1 18. The remote data processing system 1 18 may query the database and retrieve 
information from the database 200 to identify and solve technical problems. For example, 
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the database 200 may contain a list of network elements or components of the remote data 
processing systems 1 1 8, and corresponding status data 1 08 on whether the components are 
active or operational. In one embodiment, the remote management system 14 determines if 
each remote data processing system 1 18 is active, operational, or responsive on a site-by-site 
basis by accessing a group of databases 200 for association with the trading partners. 

The feedback generator 164 may be coupled to the fault detector 165. When the 
business-to-business system is fully functional, the feedback generator 164 may recirculate a 
status indicator (e.g., a dummy or known sequence bit stream) that is received from the base 
data processing system 12 by the data receiver 172. The feedback generator 164 may verify 
the presence of the status indicator at a last stage (e.g., third stage software component 163) 
of the remote software module 160. If the status indicator is present at the last stage, the 
feedback generator 164 may forward the status indicator or regenerate the status indicator for 
transmission back to base the data processing system 12 or the remote management system 
14. The status indicator may be directed to the transmitter 1 18 for transmission to the base 
data processing system 12 as an indicator that all of the stages of the remote software module 
160 are functioning and the communications network 16 is operational. 

The circulation of the status indicator flows from the base data processing system 12 
to the remote data processing system 1 18 and then back to the base data processing system 
12 for detection by the remote management system 14. The circulation may be referred to as 
a heart-beat indicator because the heart-beat indicator may be configured to be present when 
the business-to-business system (e.g., trading system) is properly operating. The heart-beat 
indicator may represent a string of known symbols or a status indicator that is generated 
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repetitively and coincident with a interval. An outbound heart-beat indicator from the base 

data processing system 12 is preferably followed by an inbound heart-beat indicator, 

thereafter, in a properly functioning system. 

FIG. 6 primarily concerns the monitoring capabilities of the remote management 

system 14, as opposed to the control capabilities of the management system 14. 

Accordingly, in an alternate embodiment, the remote management system 14 of FIG. 6 may 

be replaced by a remote monitoring system. 

Once a technical problem is detected or discovered, the remote management system 

14 may access the database 200 at the remote data processing system 1 18 to retrieve any 
error messages that the fault detector 165 or the remote status reporter 156 have logged and 
recorded in the database 200. The management system 14 may present error messages (e.g., 
error codes) to a user via a graphical user interface, start the flow of error messages for 
receipt at the management system 14, and stop the receipt of error messages for reviewing at 
the management system 14. The management system 14 may view the transactions or 
operation of the remote software module 160 when the software module is operational. The 
management system 14 may instruct the remote data processing system 1 18 to reprocess a 
data message, transactional data 101, or other business data if an error occurs. 

The remote management system 14 may send a reset message or a restart message to 
reset or restart one or more of the following components of the remote data processing 
system 18: the first stage software component 161, the second stage software component 
162, the third stage software component 163, and the remote software module 160. The 
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remote management system 14 may also shut down a particular stage or stages of the remote 
software module 1 60 on a stage-by-stage basis, or otherwise. 

If the remote software module 160 or a stage remains non-responsive after the 
resetting or restarting, the remote management system 14 has the capability to remotely 
change technical parameters associate with the remote software modules 160, to remotely 
change technical parameters associated with any stage software component, and to remotely 
upgrade a portion of a software module or an entire software module or component via the 
communications network 16. The upgrading of a technical parameter may be preferred to 
upgrading an entire program or software module because of the lesser bandwidth or 
communication resources of the communications network 16 required to transmit technical 
parameter data than an entire program, for example. Moreover, technical parameters may be 
changed more quickly because of the elimination of the need to transmit a software module 
or software component, followed by installation of the software module or component at the 
remote data processing system 118. 

The forgoing control and management features of the remote management system 14 
may facilitate ready replacement of corrupt data, incompatible program components, and 
remedying of software bugs. Software patches are readily and quickly distributed to all 
members of the trading group to solve certain problems. 

FIG. 7 shows a hub and spoke arrangement of a business-to-business trading system 
in accordance with the invention. The business-to-business trading system applies to trading 
partners of a single trading group, for example. Although a first trading partner's 
infrastructure 166, a second trading partner's infrastructure 167, and a third trading partner's 
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infrastructure 168 are shown in FIG. 7, in practice virtually any number of trading partners of 
a trading group may participate with their associated infrastructure. Each trading partner's 
infrastructure may be located at a different geographic site. A trading partner's infrastructure 
(166, 167 and 168) may comprise a data processing system 171 (e.g., a business-to-business 
server or a base data processing system 12) coupled to a business system 170 (e.g., a primary 
business system) and a remote management system 14. 

The remote management system 14 may be applied to the infrastructure of at least 
two different trading partners (e.g., at all trading partner sites). FIG. 7 differs from the 
configuration of FIG. 1 in that the remote management system 14 of FIG. 1 was controlled by 
and only present at a primary business entity or primary service provider. Here, the presence 
of multiple remote management systems 14 in the same trading group facilitates shared 
management of the business-to-business system among the trading partners to distribute 
maintenance and operational expenses within the trading group. For example, the trading 
partners may agree to staff only one of the management systems 14 at any given time, during 
alternating time periods, or in accordance with a schedule to distribute labor costs among 
employees or workers affiliated with different trading partners. Further, even if the trading 
partners do not share the responsibilities of monitoring the system or updating software 
modules, the trading partners may assist one another to resolve technical disputes from 
different perspectives available from remote management systems 14 distributed at different 
sites. 

FIGs. 8A and 8B represent a flow chart of an update procedure for updating a remote 
software module 60 resident in a remote data processing system 18 remotely via a 
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communications network 16 and the management system 14. The method of FIG. 8 A and 
FIG. 8B begins in step S20. 

In step S20, a management system 14 or a base data processing system 12 
communicates with one or more remote data processing systems 18 (e.g., remote business-to- 
business servers) associated with trading partners on technical parameters of software, 
hardware, or both of each remote data processing system 18. For example, the management 
system 14 polls remote data processing systems 18 associated with trading partners on 
technical parameters (e.g., operational status) of software, hardware or both of each remote 
data processing system 1 8. If the base data processing system 12 handles the polling of 
different remote data processing systems 18, the base data processing system 12 may route, 
direct, or forward any response of the remote data processing systems 18 to the management 
system 14. 

In an alternate embodiment, one or more remote data processing systems 18 may 
report technical parameters of software, hardware, or both to the management system 14 on a 
contention basis, rather than a polling basis. In a contention scheme, each remote data 
processing system 18 may transmit a report message upon the occurrence of one or more of 
the following: detection of new information on the operational status, the detection of new 
information on technical parameters, and the expiration of a timer. In one version of a 
contention scheme, if two remote data processing systems 18 attempt to transmit the report 
message to the management system 14 at the same time, the managing communications 
interface 28 may assign a temporary priority level to each of the remote data processing 
systems via the remote communications interface 52 to determine the sequence of 
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transmission. In another version of a contention scheme, if two remote data processing 
systems 18 attempt to simultaneously transmit report messages to the managing 
communications interface 28, the managing communications interface 28 may invoke the 
remote communications interface's assigning of a random transmit time for the report 
messages to avoid the conflict. 

In step S22, the management system 14 receives a report message or an indication on 
at least one of the technical parameters via the communications network 16. In one 
embodiment, the report message may constitute an acknowledgement. The indication may 
constitute the lack of an acknowledgement that indicates disablement of particular remote 
data processing system 18 where the management system 14 expects a certain 
acknowledgment in response to a polling message transmitted in step S10 to the particular 
remote data processing system 18. 

The technical parameter or parameters of the remote data processing system 18 
include one or more of the following items: a type of software module installed in a 
corresponding remote data processing system 18, a version of a software module or software 
installed in the corresponding remote data processing system 18, the active or available 
features that have been activated or authorized for use by the corresponding remote data 
processing system 18, hardware specifications of the remote data processing system 18, 
software specifications on an active remote software module 60, application specifications, 
operating system specifications, and operational status data. The technical parameters may 
be expressed as technical parameter data. 
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The operational status includes the execution or ongoing execution of processing by a 
particular remote data processing system 18 associated with a corresponding remote 
identifier. The operational status data may indicate whether the performance of the remote 
data processing system 18 complies with a target performance metric (e.g., a target 
executable time per transaction). For example, the operational status data may indicate 
whether a particular remote data processing system 18 is operational or disabled with respect 
to executing one or more transactions. 

In step S24 at the management system 14 or the a database manager 44 retrieves 
reference technical parameter data on hardware, software or both from a reference 
parameters database 46. The reference parameters database 46 may store reference technical 
parameter data on reference technical parameter (e.g., reference operational data or a 
reference performance metric target).. The reference technical parameter data may define a 
requisite configuration for one or more remote data processing systems 18 to foster 
compatibility with the base data processing system 12. 

In one embodiment, the reference technical parameter data include groupings of a 
reference base software module 22 and one or more reference remote software module 60 
that are compatible with the reference base software module 22. The grouping may coincide 
with trading groups. Any software modules may be defined by type of software module, 
version of the software module, or a module identifier that indicates type of the software 
module and the version of the software module. 

In another embodiment, the reference technical parameter data may include a latest 
feature set or desired feature set for conducting business-to-business transactions with the 
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trading partners via a communications network 16. The latest feature set may establish a 
desired configuration for each remote data processing system 18 and the base data processing 
system 12 of a trading group. The trading partners of the trading group may contractually 
agree to the latest feature set of the desired feature set or reach a consensus for the desired 
feature set in another manner. 

The reference technical parameter data in the reference parameters database 46 may 
be entered via a user interface 34. For example, a service provider or technician may enter 
desired or aspirational reference technical parameter data into the reference parameters 
database 46 for upgrading and maintaining the functionality of the business-to-business 
environment among the trading partners. The level of performance and the finances required 
to achieve a desired level of performance may require some degree of balance and judgment 
by a service provider. Accordingly, the reference parameter data in the reference parameters 
database 46 may represent the consensus of the trading partners on what level of 
performance, which may be less than aspirational technical parameters, is acceptable for 
conducting business over the communications network 16. The consensus may also be 
delegated to the service provider who controls the management system 14 and is bound to 
adhere to a certain budgetary constraint for example. From time to time, a service provider 
may update the reference database 46 to achieve enhanced functionality or to add new 
features to the business-to-business environment. 

In step S26 following step S24, a data processor 30 of the management system 14 
determines if the received technical parameter data in the report message from the remote 
status reporter 56 of the remote data processing system 18 complies with or matches the 
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reference technical parameter data retrieved from the reference parameters database 46. The 
data in the reference parameters database 46 may be organized be remote identifiers of 
different remote data processing system 18. The remote identifier may indicate the identity 
of a particular corresponding remote data processing system 18 or the identity of a business 
entity affiliated with the remote data processing system 18. 

The comparison in step S26 preferably compares the reference technical parameter 
data with the received technical parameter data on a remote-identifier basis, where each 
trading partner has a remote identifier associated with a corresponding remote data 
processing system 18. If the data processor 30 determines that the received technical 
parameter data of the particular data processing system (e.g., next business-to-business 
server) complies with or matches the reference technical parameter data then the method 
continues with step S28. However, if the data processor 30 determines that the received 
technical parameter data of the particular data processing system does not comply with or 
match the reference technical parameter data then the method continues with step S32. 

In step S28, the processor determines if all of the remote data processing systems 18 
(e.g., business-to-business servers) in a defined group (e.g., trading group) have been 
checked for compliance with the applicable reference technical parameter data. That is, the 
processor determines if the remote data processing systems 18 affiliated with each trading 
partner have been previously evaluated in accordance with step S26. If all of the remote data 
processing systems 1 8 in the defined group have not been checked for compliance with the 
reference technical parameter data, then the method continues with step S26, wherein the 
next remote data processing system is evaluated. A counter may be incremented each time 
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the received parameters of a different remote data processing system 18 are evaluated until 
the counter reaches the total number in the defined group. Once the counter reaches the total 
number of the defined group, all of the remote data processing systems 18 within the group 
have been considered. Ac cordingly, if all of the business-to-business servers in a defined 
group have been checked for compliance with the reference technical parameter data, then 
the method ends in step S30. 

In step S32, which may follow step S26, the data processor 30 determines if the same 
type of software modules are specified in the reference technical parameter data as the . 
received technical parameter data with respect to a particular remote data processing system 
18. If the same type of software modules are specified in both the reference technical 
parameter data and the received technical parameter data, then the method continues with 
step S36. If different types of software modules are specified in the reference technical 
parameter data and the received technical parameter data, then the method continues with 
step S34. 

In step S34, the management system 14 or a communications interface (e.g., base 
communications interface 26) sends or allocates a new software module to the particular 
remote data processing system 18 to remedy the detected discrepancy of the software type of 
step S32. For example, the management system 14 may retrieve a software upgrade module 
from an upgrade module database 50 and authorize the transmission of the retrieved software 
upgrade module to the remote data processing system 18 via the communications network 
16. 
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Here, the particular remote data processing system 18 refers to an upgrade candidate 
that is identified based on the detected deficiency. If the particular remote data processing 
system 18 has the requisite hardware to support the upgrade software module, a remote status 
reporter 56 of the data processing system may send a hardware status report to the 
management system 14 with the remote identifier of the remote data processing system 18 
and technical parameter data to indicate that the hardware is capable of supporting a new 
upgrade module. However, if the particular remote data processing system 18 lacks the 
requisite hardware to adequately support the upgrade software module, a remote status 
reporter 56 may send technical parameter data (e.g., a hardware status report) to the 
management system 14 so indicating along with the remote identifier. 

The management system 14 may handle the transmission of the upgrade to the remote 
data processing system 18 in accordance with various alternative techniques. Under a first 
technique, the upgrade software module is not sent to the remote data processing system 18 
until the remote data processing system 18 is authorized to install the upgrade software 
module by a confirmation of readiness or preparedness from the remote status reporter 56 of 
the remote data processing system 18 to be upgraded. For example, upon receipt of a 
confirmation of adequate hardware to support the upgrade software module at the particular 
remote data processing system 18, the management system 14 may authorize transmission or 
transmit the upgrade module to the remote data processing system 1 8 via the 
communications network 16. 

In accordance with a second technique for upgrading the software, the upgrade 
software module may be sent to the remote data processing system 1 8 even though the 
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remote data processing system 18 is not authorized to actually execute the upgrade. In such 
case the base data processing system 12 sends an upgrade software module from the upgrade 
module database 50 with a wait flag to indicate that the remote control module 54 should not 
install the upgrade module until it is authorized to do so from a follow-up communication 
from the management system 14. For example, a remote status report from the remote data 
processing system 18 to the management system 14 may trigger the installation of the 
upgrade module into the remote data processing system 18 to replace an existing active 
remote software module 60 upon approval from the management system 14. The wait flag is 
removed once authorization is received to execute the upgrade. 

In step S36, the data processor 30 or management system 14 determines if the same 
version of the software module is present in the received parameters data and in the retrieved 
reference parameter data. The version of the software module may impact the features that 
are available in the same type of software module or the interoperability of software 
modules. For example a software module of an earlier version and a later version may or 
may not be compatible. Similarly, an earlier version of the software module may require less 
rigorous or less elaborate hardware components than a later version of the same type of 
software module. In general, each remote software module 60 may be associated with a 
version identifier and a general module identifier to facilitate comparison of the different 
software modules. 

If the data processor 30 or management system 14 determines that the same version of 
the software module is present in the received technical parameter data as that specified in 
the referenced technical parameter data, then the method continues with step S40. However, 



-35- 

if the same version of the software modules is not specified in the referenced technical 
parameter data and the received technical parameter data, then the method continues with 
step S38. 

In step S38, the managing communications interface 28 or the management system 14 
sends or allocates a desired version (e.g., latest version) of the software (e.g., a new remote 
software module) to the particular remote data processing system 18 with a particular 
identifier consistent with the software version deficiency identified in step S36. Here, the 
particular remote data processing system 18 refers to the remote data processing system 18 
with the software version deficiency noted in step S36. 

The management system 14 may handle the transmission of the latest or desired 
version of the upgrade to the remote data processing system 18 in accordance with various 
alternative techniques. Under a first technique, the desired version of the upgrade software 
module is not sent to the remote data processing system 18 until the remote data processing 
system 18 is authorized to install the upgrade software module by a readiness confirmation 
from the remote status reporter 56 of the particular remote data processing system 18 to be 
upgraded. For example, upon receipt of a confirmation of adequate hardware to support the 
upgrade software module at the particular remote data processing system 1 8, the 
management system 14 may authorize transmission or transmit the desired version of the 
upgrade software module to the remote data processing system 18 via the communications 
network 16. 

In accordance with a second technique for upgrading the version of the software, the 
desired version of the upgrade software module may be sent to the remote data processing 
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system 18 even though the remote data processing system 18 is not authorized to actually 
execute the final installation of the upgrade. In such case the base data processing system 12 
sends the desired version of the upgrade software module from the upgrade module database 
50 via the database manager 44 with a wait flag to indicate that the remote control module 54 
should not install the desired version of the upgrade module until it is authorized to do so 
from a follow-up communication from the management system 14. For example, the remote 
status report from the data processing system may trigger the installation of the upgrade 
module into the remote data processing system 18 to replace an existing active remote 
software module 60 upon approval from the management system 14. The wait flag is 
removed once authorization is received to execute the installation of the desired version of 
the upgrade. 

Step S40 may follow step S36 or step S38. In step S40, the data processor 30 or 
management system 14 determines if a hardware upgrade or additional hardware is required 
to support the planned installation of the upgrade software module, a new software module 
or the desired version of the software module. The remote control module 54 confirms 
whether the remote data processing system 18 has the requisite hardware to support the 
desired or latest version of the software module, either prior to sending the desired version of 
the software module to a remote data processing system 18 via the communications network 
16 or prior to authorizing the remote data processing system 18 to install the sent upgrade 
software module into the remote data processing system 18. At the remote data processing 
system 18, the remote control module 54 may seek the receipt of an approval from the 
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management system 14 before implementing or installing any received upgrade module from 
the management system 14. 

If the processor determines that additional hardware upgrade or additional hardware 
is required to support the planned installation, then the method continues with step S42. 

> However, if the processor determines that a hardware upgrade is not required to support the 

planned installation of the upgrade software module or the particular desired version of the 
upgrade software module, then the method continues with step S44. 

In step S42, the presentation module 42 or the management system 14 generates an 
alert message for presentation of a user interface 34. The alert message may inform a user 

) that a hardware upgrade may be required for the particular remote data processing system 1 8. 

Accordingly, the management system 14 may wait prior to sending an upgrade software 
module or an authorization to install the upgrade software module in the remote data 
processing system 18 via the communications network 16. 

The authorization or validation may occur where the remote data processing system 

i 18 generates a status report from the status reporter 56 that indicates that a hardware revision 

has taken place. The hardware specifications may be sent to the management system 14 as 
technical parameter data and the base data processing system 12 or the management system 
14 may generate an approval message that authorizes the installation of the remote software 
module upgrade resident in or transmitted to the remote data processing system 18. 

) In step S44, the remote data processing system 18 revises the software configuration 

of the remote data processing system 18 based on the receipt of one or more of the following 
items: an appropriate versi on of the software to overcome a software version deficiency 
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noted in step S36, an appropriate upgrade software module to overcome a software type 
deficiency noted in step S32, a latest version of an upgrade software module, and a new 
software module. The revision module at the remote data processing system 18 is 
responsible for revising or updating the software configuration of the remote data processing 
system 18. For example, the revision module may replace an outdated, active remote 
software module 60 with an upgrade software module received from the management system 
14 upon approval of the management system 14 or otherwise. 

In step S46 following step S44, the monitor 36 of the management system 14 may 
confirm replacement or revision by querying or checking the operational status of the revised 
or upgraded remote data processing system 18 via a direct request via the communications 
network 16 or incidental to a polling procedure for monitoring operational status of the 
remote data processing system 1 8. For example, the remote data processing system 18 may 
send an acknowledgment that the revision module has successfully revised the software 
module within the remote data processing system 18. 

If the replacement or revision is monitored pursuant to a polling procedure, the 
management system 14 may experience a delay of one polling cycle before the confirmation 
is received. In contrast, the direct request via the communications network 16 may produce a 
rapid turnaround time. 

Following step S46, the method may return to step S28. The base data processing 
system 12 may be affiliated with a primary trading partner at a primary site, whereas the 
remote data processing systems 18 may be affiliated with secondary trading partners that 
receive information technology service and upgrades of their remote data processing 
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systems 18 via the primary trading partner or an affiliated service provider. The return to 
step S28 ensures that the management system 14 has considered the remote data processing 
systems 18 of each of the secondary trading partners. The defined group of trading partners 
specified in step S28, and generally in FIG. 8A and FIG. 8B, may be, but need not be, 
restricted to less than all of the available trading partners of a trading group to meet the 
particular needs and circumstances of the primary and secondary trading partners. 

The method of FIG. 9 A and FIG. 9B shows a flow chart of managing a remote data 
processing system that supports adding or removing a feature from one or more remote data 
processing systems 18 in accordance with the invention. Like steps in FIG. 8 A and FIG. 8B 
are indicated by like reference numerals in FIG. 9 A and FIG. 9B. The method of FIG. 9A 
and FIG. 9B is similar to the method of FIG. 8A and FIG. 8B except the method of FIG. 9A 
and FIG. 9B includes step SI 8. 

Step S 1 8 precedes step S20. In step S 18, a user at the management system 14 may 
enter data on revising the reference technical parameters and the reference parameters 
database 46 such that a reference configuration for a corresponding remote data processing 
system 18 reflects a new feature for installation at the remote data processing system 18 (e.g., 
remote business-to-business server). The reference parameter data within the reference 
parameters database 46 may be specified on a remote-identifier basis such that each 
secondary trading partner is compatible with the base data processing system 12 for a trading 
group. Further, each secondary trading partner within the trading group may be configured 
identically or differently so long as compatibility with the base data processing system 12 of 
the trading group is maintained. Accordingly, different remote data processing systems 18 
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may support different features depending upon the needs of the trading partners within the 
trading group. 

The reference parameter data may be grouped according to one or more remote 
identifiers of corresponding remote data processing systems 18. The reference parameter 
data may include hardware specifications, software specifications, a presence of a particular 
type of software module, the absence of a particular type of software module, a desired 
version (e.g., a latest version) of a software module, the desired version of an operating 
system, the type of an operating system, or other parameters that may affect the operation 
and reliability and interoperability of the remote data processing system 1 8 with the base data 
processing system 12 via the communications network 16. 

FIG. 10 shows an alternate embodiment of the data processing system. Like 
reference numerals in FIG. 1 and FIG. 10 indicate like elements. The system of FIG. 10 is 
similar to the system of FIG. 1 except the system of FIG. 10 includes firewalls as a security 
measure to protect the integrity of the data shared by the trading group from tampering by 
unauthorized users. 

The base data processing system 12 may be associated with one or more firewalls. 
Similarly, the remote data processing system 18 may be associated with one or more 
firewalls. In one embodiment, an outer firewall 66 is placed in the communication path 
between the communications network 16 and a data processing system (e.g., base data 
processing system 12 or a remote data processing system 18), whereas an inner firewall 68 is 
disposed in a communications path between the remote data processing system 1 8 and a 
secondary business system 72. A firewall, inner firewall 68, or outer firewall 66 refers to 
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software, hardware, or both that filters or blocks the passage of data messages that meet a 
defined security criteria. The defined security criteria may represent a source identifier, a 
destination identifier, a content indicator, or some other attribute associated with the data 
message. The source identifier and destination identifier may be found in a header of a data 
packet under certain data protocols, for example. 

The management system 14 and method of the invention facilitates the primary 
business entity or an affiliate acting as a service provider for maintaining the remote data 
processing systems 18 within a defined trading group. The service provider may maintain 
control over the remote data processing systems 18 and their components even though the 
remote data processing systems 18 may be widely geographically dispersed across the United 
States or in foreign countries. The service provider can keep the software of the trading 
partners or secondary business entities in step with each other and the primary business entity 
to promote technical interoperability and timely cost-effective upgrades of software features. 

The foregoing description of the system and method describe several illustrative 
examples of the invention. Modifications, alternative arrangements, and variations of these 
illustrative examples are possible and may fall within the scope of the invention. 
Accordingly, the following Claims should be accorded the reasonably broadest 
interpretation, which is consistent with the specification disclosed herein and not unduly 
limited by aspects of the preferred embodiments disclosed herein. 



